Semantic compliance validation for blockchain

ABSTRACT

A method may include receiving, at a computing device, an electronic data structure, the electronic data structure including: a location of a validation source for a payload of the data structure; and the payload, wherein the payload identifies a plurality of elements of a transaction; retrieving, from the validation source, a semantic schema; validating the payload of the data structure according to the semantic schema; and based on a result of the validating indicating the payload complies with the semantic schema, appending an electronic compliance signature to the data structure.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/368,120, filed Dec. 2, 2016, which is a Non-Provisional of and claimsthe benefit of priority under 35 U.S.C. § 119(e) from U.S. ProvisionalApplication Ser. No. 62/262,047, filed on Dec. 2, 2015; 62/314,333,filed Mar. 28, 2016; and 62/319,837, filed Apr. 8, 2016, each of whichare hereby incorporated by reference herein in their entirety.

TECHNICAL FIELD

Embodiments described herein generally relate to parsing data structuresand in particular, but without limitation, to semantic compliancevalidation for blockchain.

BACKGROUND

A blockchain may contain one or more blocks. A block may include one ormore data entries. A hash may be included in each block that is based onthe content of previous blocks in the blockchain.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numeralsmay describe similar components in different views. Like numerals havingdifferent letter suffixes may represent different instances of similarcomponents. Some embodiments are illustrated by way of example, and notlimitation, in the figures of the accompanying drawings in which:

FIG. 1 is a diagram depicting relationships between objects that may bein a contract, according to various examples.

FIG. 2 is a semantic representation of a sentence, according to variousexamples;

FIG. 3 illustrates a schematic diagram of validating a data structure,according to various examples;

FIG. 4 is a diagram illustrating a semantic representation of aninterest rate swap, according to various examples;

FIG. 5 illustrates a flowchart of a method of adding a compliancesignature to a data structure, according to various examples;

FIG. 6 illustrates a schematic diagram of a system of using smartcontracts and a blockchain;

FIG. 7 illustrates a schematic diagram of auditing and reporting using ablockchain, according to various examples;

FIG. 8 illustrates a schematic diagram of a system for generating areport block, according to various embodiments;

FIG. 9 illustrate a diagram of a logic annotation, according to variousembodiments,

FIG. 10 illustrates a schematic diagram of a report block, according tovarious embodiments; and in which

FIG. 11 illustrates a flowchart of a method of, according to variousexamples

FIG. 12 is a block diagram illustrating an example machine upon whichany one or more of the techniques (e.g., methodologies) discussed hereinmay be performed, according to an example embodiment.

DETAILED DESCRIPTION

An ontology may be as a taxonomy of objects for a given field—differentfields may use different ontologies. The ontology may identify types,properties, and interrelationships between the objects. When used in theelectronic realm, an ontology may be used to determine if data complieswith the ontology. In some examples, the definition of an ontology isdescribed a schema.

As a simple example, consider a schema for a Person object. The schemamay include a number of entries that define the properties of a Personobject such as “given name,” “height,” “weight,” etc., and theproperties may also have expected types. Thus, the “height” property mayhave a quantitative type where as “given name” may be text. The exceptedtype of an object may be another object such as a property of “knows”having an expected type of Person. Accordingly, the data string “Aliceknows Bob” can be thought of as two Person objects with the Alice havingthe “knows” property.

Another way to consider ontologies is using a “Subject, Predicate,Object” (S-P-O) format. Using the example of “Alice knows Bob,” Alice isthe subject, the predicate is “knows,” and the object is “Bob.” Withreference back to the example Person schema, the predicate is theproperty in the schema and the expected type is the object. In otherwords, a schema may semantically define valid relationships betweenmultiple objects.

As another example, consider FIG. 1 depicting relationships betweenobjects that may be in a contract. Industry groups may promulgateschemas/ontologies for use by their members or for communicating withtheir members. For example, the Financial Industry Business Ontology(FIBO™) identifies numerous objects and their semantically definedrelationships common in the financial industry—such as depicted in FIG.1 . While the majority of this disclosure is focused on financial termsand use cases, the same methods can be applied to any industry (e.g.,retail, health care, etc.).

FIG. 2 illustrates the concept of “Corporate Ownership” as used in asemantic ontology, according to an example. The example uses the S-P-Oformat discussed above. One flexibility of a semantic ontology is thatdata from any number of sources may be standardized and harmonized.Accordingly, once a data store (e.g., file system, relational database,NoSQL database, flat file database) is populated with enoughsemantically intact data, the data may be mined, stored, queried,audited, and validated. The data may originate in a number of forms suchas unstructured data, a spreadsheet, a relational database, ExtensibleMarkup Language (XML), JavaScript Object Notation, etc.

In some instances, a service (e.g., a web service) may map or translatethe various formats into a common format for easier data mining. Forexample, a webpage may include the unstructured data “Global Bankowns>50% voting shares of London Bank.” This data may be parsed into theS-P-O format of subject: Global Bank; predicate: owns; and object:London Bank. At this point, the service may update a database toindicate the relationship between Global Bank and London Bank accordingto a defined schema.

Regulators, or other users, may use this information when analyzing morecomplex transactions. For example, after enough data has been inputtedinto a data store, regulators—as well as financial institutions—mayquickly perform systemic risk analysis or compliance with regulation W.Other use cases may be readily apparent to a person of ordinary skill inthe art without departing from the scope of this disclosure and may varydepending on the technology area.

Problems may arise when large amounts of data is assumed to be compliantwith an ontology but fails to meet the requirements of the ontology. Invarious examples, a web service may be provided that validates dataaccording to a known schema and provides a digital compliance signatureindicating the data is valid.

FIG. 3 illustrates a schematic diagram 300 of validating a datastructure, according to various example embodiments. The diagram 300illustrates validating system 302, unvalidated data structure 304,validated data structure 306, and blockchain 308. The validating system302 includes compliance subsystem 310, classification subsystem 312,attribution subsystem 314, and signature subsystem 316, according tovarious examples.

In various examples, the servers and components of the diagram 300 maycommunicate via one or more networks (not shown). The networks mayinclude local-area networks (LAN), wide-area networks (WAN), wirelessnetworks (e.g., 802.11 or cellular network), the Public SwitchedTelephone Network (PSTN) network, ad hoc networks, cellular, personalarea networks or peer-to-peer (e.g., Bluetooth®, Wi-Fi Direct), or othercombinations or permutations of network protocols and network types. Thenetworks may include a single local area network (LAN) or wide-areanetwork (WAN), or combinations of LAN's or WAN's, such as the Internet.

The validating system 302 may provide an Application ProgrammingInterface (API) to publishers of a transaction. A publisher may be anyentity that wants to have data validated against an ontology. Within thefinancial industry, a publisher may be a financial institution such as abank, corporation, brokerage, closing company, etc. A transaction may bea set of data that defines one or more properties of an entity within anontology. For convenience, FIG. 3 will be discussed as an interest rateswap between two banks.

FIG. 4 is a diagram illustrating a semantic representation of aninterest rate swap, according to various examples. In order to have theinterest rate swap considered valid by other sources, the interest rateswap may be encapsulated into a format for validation by the validatingsystem 302. Examples of encapsulation formats include, but are notlimited to, XML and JavaScript Object Notation-Linked Data (JSON-LD). Anaddition component of JSON-LD is the identification of a schema that thepayload of the JSON-LD is supposed to adhere to (referred to as thevalidation source in FIG. 3 )

For example, the following JSON-LD encoding may be used for a swapcontract such as displayed in FIG. 4 :

  { “@context” : { “@vocab” : “http://spec.edmcouncil.org/fibo/Swaps/”}, “type” : “SwapContract”, “hasIdentifier” : “Swap1001”,“hasSwapStream” : [ { “type” : “SwapStream”, “hasPayerParty” : { “@type“Party”, “hasLegalEntityIdentifier” : “LEI5001”}, “hasRate” : “0.05” },]“hasSwapStream” : [ { “@@type” : “SwapStream”, “hasPayerParty” : {“(@type “Party”, “hasLegalEntityIdentifier” : “LEI7777”},“hasFloatingRateIndex” : { “@type “RateIndex”, “hasIdentifier” : “LIBOR”},] }

The validating system 302 may include at least one web server to respondto API calls from publishers of data, such as unvalidated data structure304. The validating system 302 may also include at least one processorto execute subsystems 310-316. The execution of the subsystems may takeplace in one physical computing device or be distributed across multiplecomputing devices. In some instances, more than one computing devicecompletes the same task (e.g., first to complete). The computing devicesmay be located in one geographic area or distributed across multiplegeographic areas.

In an example, the compliance subsystem 310 compares the payload ofunvalidated data structure 304 to a schema as defined by the validationsource. Validating may include retrieving the rules for the variousentities in the payload checking for their compliance. For example, theschema may indicate that the type “SwapContract” requires two “Party”types. If the payload fails to include two parties, the unvalidated datastructure 304 would be rejected as failing to comply with the schema andnot added to a blockchain. In an example, the compliance subsystem 310calls a third-party service to check the payload for validation.

The classification subsystem 312 may modify the payload if additionalclassifications of objects can be inferred by data in the payload. Usingthe example above, the JSON-LD states the first type is that of a“SwapContract” with one leg having a “hasRate” type and the second leghaving a “FloatingRateIndex” type. The schema identified in thevalidation source may indicate that a SwapContract that includes the“hasRate” type and the “FloatingRateIndex” type is properly classifiedas a “FixedFloatInterestRateSwapContact.” Accordingly, classificationsubsystem 312 may modify “SwapContract” to“FixedFloatlnterestRateSwapContact.”

In some instances a data structure examined by validating system 302includes a digital signature of the publisher. The digital signature maybe a hash of the payload (or of the payload and validation source)encrypted using the private key of the publisher. The attributionsubsystem 314 may retrieve the public key—either included with theJSON-LD message or from a registry—of the publisher to decode the hashof the payload. The attribution subsystem 314 may also create a hash ofthe payload which is compared with the decoded hash. If the two hashesmatch, the publisher may be considered verified. Other types ofattribution techniques may be used without departing from the scope ofthis disclosure.

If both the compliance subsystem 310 and attribution subsystem 314indicate the payload complies with the schema, and is properlyattributable to the publisher, the signature subsystem 316 may attach acompliance signature to the unvalidated data structure 304 to createvalidated data structure 306. The compliance signature may be based ahash the payload and optionally the validator source and publishersignature. The hash may be signed using the private key of thevalidating system 302. The validated data structure 306 represents anexample format of a compliance signed data structure.

After a compliance signature has been added to a data structure, thevalidated data structure 306 may be added to a blockchain. In someinstances, the payload is not included in the blockchain, but onlysigned hashes of the payload. The blockchain may include all theprevious swap contracts; although the blockchain may not be limited toonly swap contracts. Accordingly, anyone with the blockchain may trustanother party that indicates the swap contract described in the exampleabove is valid based on the signed hash or signed payload outputted byvalidating system 302.

In some instances, adding the validated data structure 306 to theblockchain is accomplished by distributing the validated data structure306 to numerous anonymous servers. The servers may need to complete acomputationally difficult calculation in order to add validated datastructure 306 to the blockchain. The calculation may require using ahash of previously added information to the blockchain. In such as amanner, the blockchain becomes difficult to improperly modify. Onceadded, the blockchain may be trusted by other parties despite theanonymous nature of the servers.

For example, similarly to how attribution subsystem 314 determines avalid publisher, a party could take the public key of validating system302 to decode the compliance signature, resulting in the hash of thepayload. The party could independently calculate the hash of the payloadand compared to the decoded hash. If the hashes match, the party canknow that the transaction in the payload is valid and attributable tothe publisher. As indicated above, in some instance the compliancesignature does not include the publisher signature in the hash. Thus, insome instances, blockchain includes the payload signed by both thepublisher and the validating system 302.

FIG. 5 illustrates a flowchart of method of adding a compliancesignature to a data structure. The method may be performed by executing,using at least one processor, instructions stored on a non-transitorycomputer-readable medium.

At operation 502, an electronic data structure may be received. Theelectronic data structure may include a location of a validation sourcefor a payload of the data structure. The location may be a uniformresource identifier that links to a semantic schema. The semantic schemamay be retrieved (operation 504). The semantic schema may identify rulessuch as names of object types (also referred to an elements), propertiesof object types, valid values for the properties, restriction onoperations of object types with respect to other object types, amongother things.

The data structure may also include a payload. The payload may identifyat least one object type, a property of the object, and a value for theproperty. Multiple objects may be included in the data structure as wellmultiple different object types. In an example, the electronic datastructure conforms to the JSON-LD format. The data structure may alsoinclude a digital signature of the publisher of the electronic datastructure.

At operation 506, the data structure may be validated according to thesemantic schema. The rules of the semantic schema may be compared to theelements of the data structure for validation. For example, propertiesincluded in the data structure may be compared to valid propertiesaccording to the schema. Similarly, the values for the properties may becompared to the valid values for the properties.

An element of the payload may be modified based on the schema. Forexample, the schema may identify a hierarchy of elements (parent/child,genus/species, etc.). The data structure may identify a genus object butan examination of the properties of the genus object may be used toinfer the genus could only be one of the species objects. Thus, thegenus object may be altered to the species.

At operation 508, based on a result of the validating indicating thepayload complies with the semantic schema, an electronic compliancesignature may be appended to the data structure. The payload may behashed and encrypted using a private key to create the electroniccompliance signature. Additionally, a blockchain that includes at leastone block with at least one transaction may be retrieved. The hashedpayload signed by the electronic compliance signature may be appended tothe blockchain. In an example, the payload with the compliance signatureis appended to the block chain instead of (or in addition to) a hashedversion of the payload.

Different version of the payload may be appended to the blockchain. Forexample, when the payload is modified as above, two versions of thepayload may be appended to the blockchain: one hashed payload with thechanges and one hashed payload without the changes. The hashes may besigned as indicated above. Additionally, sometimes the hash may includethe digital signature of the publisher and other times the hash may becreated without the digital signature.

Standardized ontologies and blockchains may have additional uses beyond,or in addition to, the data validation methods described above. Forexample, smart contracts may leverage the ontology in describing thecomponents of a contract. A smart contract may be a contract that isdescribed in terms of an electronic program construct as opposed towritten in prose. A smart contract may be partially or completelyautomated.

A smart contract may define, programmatically (e.g., functionally,procedural), conditional logic with respect to the performance of thecontract. For example, consider a relatively straightforward exchangestock purchase. Via a broker, a user may offer to purchase X dollarsworth of a stock at a certain price. The user may an account with thebroker with money set aside for the purchase. Upon the stock being atthe price, the broker may purchase the stock on behalf of the user anddebit the user's account. Conceptually, a smart contract may have acondition of “IF stock XYZ>=$45 a share, THEN purchase 5 shares ANDdebit account the purchase price.”

The state of the contract may be stored in blockchain. In other words,each variable of a contract (e.g., the stock price in the previousexample) may have a value on the blockchain (as well as the history ofits value). Because the execution of the contract is generally fullyautomated, fraud may occur if one party updates the state of thecontract with an invalid/incorrect value. For example, if a nefariousparty changes the state to indicate there is more money in an accountthen there is actually is a stock trade may execute even if there is notenough money to cover the cost of the purchase.

FIG. 6 illustrates a schematic diagram of a system of using smartcontracts and a blockchain. The system illustrates blockchain provider602, a first party 604, a second party 606, and a blockchain 608. Theblockchain 608 includes a number of blocks identified as contracttemplate block 610, block 612 and block 614.

One solution to the invalid values problem described above, is to use astateful blockchain. In contrast to a stateless blockchain, such as usedwith bitcoins, a stateful blockchain maintains the values—in this casecontract values, among other operational values. The blockchain 608 maytherefore be queried to see if a contract may be completed. The benefitsof a blockchain is one of trust in a decentralized environment. A query,or update of variable, may be calculated by a number of participatingnodes to arrive at the true value of a variable. If a single bad actortries to change a value, the other nodes will reject it and it will notbe added to the blockchain.

The blockchain may also include a template for different contracts. Thecontract templates may be defined according to an ontology, such asFIBO. The format of the data entered on the blockchain 608 may be aJSON-LD encoding adhering to FIBO. The blockchain 608 may be public orprivate, and may have access right restrictions.

One requirement for a contract may be a contract identifier. Thecontract identifier may be used by all parties to the contract. Forexample, consider that the contract trade in FIG. 6 is a swap contract.As described above, a JSON-LD encoding may be used for the swap contractand may begin:

  { “@context” : { “@vocab” : “http://spec.edmcouncil.org/fibo/Swaps/”}, “@type” : “SwapContract”, “hasIdentifier” : “Swap1001”,“hasSwapStream” : [ . . .The “Swap1001” may identify the swap and both party A and party B mayuse it.

Furthermore, the identifier may be used by to find confirmation of thetrade across blocks of the blockchain 608. For example, the confirmationof the trade for party A may be in block 612 and the confirmation of thetrade for party B may be in block 614. In various examples, theidentifier may be hashed onto the blockchain to cryptographically pointto two (or more) disparate parts of the blockchain 608. The hash may besuch that the hash may not be used for a different swap. Again, this isdifferent than the stateless blockchain of bitcoin in which anonymityand non-traceability are features. The identifier may be generated bythe party that initiates the contract.

Another benefit of a stateful blockchain is one can see the state of acontract evolve over time. As mentioned, a smart contract may have anumber of terms and conditions. The blockchain 608 may be examined tosee which of these conditions have been met and when they were met. Theblockchain 608 may also indicate that when a contract has beencompleted, when both sides of a contract confirm the contract, etc. Thecontract may also trigger execution of other transactions, also storedon the blockchain 608 (e.g., the state of a variable may triggerexecution).

Another benefit of a standardized ontology (optionally with validationsignatures) on a blockchain is for auditing purposes. Regulations mayrequire that each entry in a report indicate where it came from, when itoccurred, other entries/transactions it implicates, etc. When everytransaction is verified, and signed as adhering to a standard ontology,auditing because much easier. For example, a federal agency may be givenkeys to unlock all, or a subset, of encrypted transaction data on ablockchain to verify reports as necessary. The inherent properties of ablockchain coupled with the signed verifications may be give the agencythe confidence that no fraudulent data is present. The data in theblockchain may also identify the location of generated regulatoryreports as well as the locations of the data necessary to validate thereports.

By way of example, the Home Mortgage Disclosure Act (HMDA) has numerousrequirements. Within an organization, each line of business (LOB) suchas mortgage, also banking, and home equity, and generate reports forcomplying with the HMDA. Quarterly, these reports may be aggregated andmanual and statistical review may take place to try and avoid anyerrors. On an annual basis, these quarterly reports may be created andprovided to the Consumer Finance Protection Bureau (CFPB) forexamination. The CFPB may then have to manually go back and examine thereports to ensure HMDA compliance.

Because of the manual nature of many of the reporting tasks, it may bedifficult to determine who put what in each report, when it was added tothe report, what calculations were used to generate the numbers inreports, and what were the sources of the data in the reports. Asdiscussed further below, the use of a blockchain provides data securityand attribution and immutability. The blockchain may be public orprivate, and may have access right restrictions.

FIG. 7 illustrates a schematic diagram of auditing and reporting using adistributed ledger (e.g., a blockchain), according to various examples.FIG. 7 includes, semantic ontology 702, financial institution 704,provenance ontology 706, app 708, app 710, distributed ledger 712, andreport 714. The lines between app 708, app 710, into the distributedledger 712 may represent report block entries. A report block entry maycomprise a series of identifiers to information needed to retrieve andverify a report, such as report 714. These entries are discussed infurther detail in FIGS. 8-10 , but an overview of the system ispresented in FIG. 7 .

The financial institution 704 may represent an entity that is requiredto provide one or more reports to one or more government agencies. Theuse of the system in FIG. 7 is not limited to such uses and may beutilized by other any organization that requires verified reporting. Thefinancial institution 704 may have its own semantic ontology 702 thatdescribes data stored within the financial institution 704. In someinstances, the semantic ontology 702 is a standardized ontology such asFIBO. In further instances the semantic ontology 702 may be a supersetof FIBO.

The provenance ontology 706 may define an ontology language to indicate,among other things, roles and identities responsible for entries in areport. Thus, in addition to providing the regulatory requirements(e.g., required data) the report may include entries in accordance withthe provenance ontology 706 that indicate where the data come from, whenit was there, etc. In some examples, the entries corresponding to theprovenance ontology 706 are stored in a separate file, such as aprovenance log. The provenance log may include entries related to one ormore reports.

FIG. 7 illustrates that financial institution 704 has a few differentlines of business (LOB). Underneath the LOBs, app 708 and app 710 aredistinguished from each other based on the line pattern. The linepatterns correspond to different blocks in the distributed ledger712—indicating different report entries associated with app 708 and 710.

The distributed ledger 712 may include a reporting block that identifiesthe various LOBs and associated apps and relevant portions of thedistributed ledger 712 related to their respective reports. Theidentification may be in the form of cryptographic pointer identifyingthe previous block of the distributed ledger 712 relevant to the report(or previous reports). That previous block may include another pointerthat identifies the “next” previous block. In such a manner, aregulatory agency may trace back-in-time through the distributed ledger712 to retrieve the relevant data for a report associated with a givenapp and verify it for auditing purposes.

FIG. 8 illustrates a schematic diagram of a system for generating areport block. FIG. 8 include report input 802, semantic ontology 804,logic annotations 806, blockchain 808, automated profiling and mappingcomponent 810, report execution component 812, report 814, semantic map816, provenance ontology 820, and provenance log 822. The variouscomponents in FIG. 8 may be distributed across multiple computingdevices in multiple geographic locations, or they may be located in asingle computing device in a single location. The execution of thevarious components may completely automated or partially automated.

The report input 802 identifies the data sources that store data for anorganization, such as a financial institution. The sources may XMLdocuments, databases, Excel documents, etc.

The semantic map 816 may in the form of R2RML, which is a relationaldatabase (RDB) to RDF mapping proposed W3C standard. One purpose ofR2RML is to facilitate a map of existing relational data—as encapsulatedin one or more databases—to the RDF data model. The input for an R2RMLmapping is a logical table that may be a base table, a view, or a validSQL query. The output of the R2RML is a mapping of the logical table toa RDF using a triple map. A triple map is a rule that takes each row inone of the logical tables to an RDF triple. The rule may have twocomponents, the subject map and a multiple predicate-object map, whichmay be made up of predicate maps and object maps. The triple for a givendatabase row may be formulated by combining the subject map with apredicate map and an object map.

The proposed W3C documentation provides the following, slightlymodified, example. Consider a database table EMP. The EMP table includesthree columns: EMPNO, ENAME, JOB. A row of the EMP table is“7639:SMITH:CLERK.” A triple map may for the EMP table may be:

  @prefix rr: <http://www.w3.org/ns/r2rml#>. @prefix ex:<http://example.com/ns#>. <#TriplesMap1>  rr:logicalTable [ rr:tableName“EMP” ];  rr:subjectMap [   rr:template“http://data.example.com/employee/ {EMPNO}”;   rr:class ex:Employee;  ]; rr:predicateObjectMap [   rr:predicate ex:name;   rr:objectMap [rr:column “ENAME” ];  ].The output of the R2RML may be

  <http://data.example.com/employee/7369> rdf:type ex:Employee.<http://data.example.com/employee/7369> ex:name “SMITH”.

In FIG. 8 , the semantic map 816 may include mappings from the semanticontology 804 to the report inputs 802. In other words, the semantic map816 may identify where, within the data sources of an organization, therelevant data for the report 814 is located.

In a simplified example, consider a report that requires all mortgagetransactions. A person or computer program—such as automated profile andmapping component 810—may first look to the semantic ontology 804 to seehow a mortgage is classified (e.g., what type of object). Then, thesemantic map 816 may be parsed to determine what columns in whatdatabase tables map to the classification. The report executioncomponent 812 may receive data (e.g., through an API) from the automatedprofile and mapping component 810 that indicates the location of datafor a given report. A report definition template may identify therequirements for a given report. For example, it may be identify whatdata is needed, in what format, for what time periods, etc.

The report execution component may also retrieve logic annotations 806to facilitate the execution of the report. The logic annotations 806 maydefine, using the semantic ontology 804, how to calculate the data for agiven report. FIG. 9 illustrate a diagram of a logic annotation.Although shown diagrammatically, the logic annotation may be stored in aXML format adhering to the semantic ontology 804.

FIG. 9 includes blockchain 902, report 904, semantic object 906, anddata source 908. Consider an auditor, which may be a computer program,that accesses blockchain 902, and a report block leads the auditor toreport 904 (discussed in further detail with respect to FIG. 10 ). Thereport 904 may reference one or more semantic objects, such as semanticobject 906. In order to determine if the value for the semantic object906 is correct, a logic annotations file may be examined. The file mayindicate how the object is used with respect to other semantic objects,as well as indicate the data sources for the semantic object. In such amanner, an auditor may independently calculate the data in the report904. In some instances, the logic annotations may include provenancedata indicating when the logic annotation file was created, who createdit, etc.

With reference back to FIG. 8 , the report execution component 812 maygenerate the report 814 using the logic annotations 806 and report input802. The report execution component 812 may also gather the locations(e.g., logical locations such as URI locations) of the data sources andattribution sources (e.g., provenance ontology 820) are located for agiven report. This information may be placed into the report block for agiven report as discussed next with reference to FIG. 10 .

FIG. 10 illustrates a schematic diagram of a report block, according tovarious embodiments. A report block may be part of a block of theblockchain. The blockchain may include hundreds, thousands, or moreblocks. A report block may include references to locations of files fora given report. The report block may include references to sources files(e.g., the underlying source of data in the report), a location of asemantic map (e.g., R2RML mappings), a reference to logic annotationsfor semantic objects in the report, a reference to a provenance log, areference to a semantic ontology used in the report, and a reference tothe underlying report itself. The report block may also include areference to a previous block in the blockchain that includes theprevious report (e.g., the report for the previous quarter). Theinformation in the report block may be encrypted, signed, or both. In anexample, the data is encrypted using a public key of a regulatory agencythat needs the report.

FIG. 11 illustrates an example method that may be performed by one ormore processors executed instructions stored in a non-transitorycomputer readable medium. In various example embodiments, a method mayinclude accessing a report definition template (1102), the reportdefinition template identifying a set of data requirement for a report.A requested report may include a report type. Each template may have acorresponding report type. Thus, a database may be queried using thereport type to retrieve the corresponding template.

The report definition file may identify logic annotations forcalculating the semantic object and wherein the location of the logicannotations are transmitted to the blockchain for adding to the reportblock.

The method may further include mapping the set of data requirements to acorresponding semantic object in a semantic ontology (1104) and parsinga semantic map to determine a database table storing data for thesemantic object (1106). The method may include retrieving the data forthe semantic object from the database table (1108). The method may alsoinclude generating a report data file adhering to the semantic objectontology based in part on the retrieved data (1110). The report datafile may the data transmitted for adding to a report block in ablockchain.

The method may also include transmitting a logical location of thegenerated report data file, a logical location of the semantic map, andlogical location of the semantic ontology to a blockchain node foradding to a report block in the blockchain (1112).

The method may also include accessing a provenance log identifying anentity that entered the data in the database table. The provenance logmay be formatted according to a provenance ontology. The logicallocation of the provenance log and the provenance ontology may betransmitted to the blockchain node for adding to the report block.

The method may further include retrieving an identifier of a previouslycomputed report using the report definition template; querying adatabase to determine a block identifier for that includes a reportblock for the previously computed report; and transmitting the blockidentifier to the blockchain node for adding to the report block in theblockchain.

Embodiments described herein may be implemented in one or a combinationof hardware, firmware, and software. Embodiments may also be implementedas instructions stored on a machine-readable storage device, which maybe read and executed by at least one processor to perform the operationsdescribed herein. A machine-readable storage device may include anynon-transitory mechanism for storing information in a form readable by amachine (e.g., a computer). For example, a machine-readable storagedevice may include read-only memory (ROM), random-access memory (RAM),magnetic disk storage media, optical storage media, flash-memorydevices, and other storage devices and media.

Examples, as described herein, may include, or may operate on, logic ora number of components, modules, or mechanisms. Modules may be hardware,software, or firmware communicatively coupled to one or more processorsin order to carry out the operations described herein. Modules mayhardware modules, and as such modules may be considered tangibleentities capable of performing specified operations and may beconfigured or arranged in a certain manner. In an example, circuits maybe arranged (e.g., internally or with respect to external entities suchas other circuits) in a specified manner as a module. In an example, thewhole or part of one or more computer systems (e.g., a standalone,client or server computer system) or one or more hardware processors maybe configured by firmware or software (e.g., instructions, anapplication portion, or an application) as a module that operates toperform specified operations. In an example, the software may reside ona machine-readable medium. In an example, the software, when executed bythe underlying hardware of the module, causes the hardware to performthe specified operations. Accordingly, the term hardware module isunderstood to encompass a tangible entity, be that an entity that isphysically constructed, specifically configured (e.g., hardwired), ortemporarily (e.g., transitorily) configured (e.g., programmed) tooperate in a specified manner or to perform part or all of any operationdescribed herein. Considering examples in which modules are temporarilyconfigured, each of the modules need not be instantiated at any onemoment in time. For example, where the modules comprise ageneral-purpose hardware processor configured using software; thegeneral-purpose hardware processor may be configured as respectivedifferent modules at different times. Software may accordingly configurea hardware processor, for example, to constitute a particular module atone instance of time and to constitute a different module at a differentinstance of time. Modules may also be software or firmware modules,which operate to perform the methodologies described herein.

FIG. 12 is a block diagram illustrating a machine in the example form ofa computer system 1200, within which a set or sequence of instructionsmay be executed to cause the machine to perform any one of themethodologies discussed herein, according to an example embodiment. Inalternative embodiments, the machine operates as a standalone device ormay be connected (e.g., networked) to other machines. In a networkeddeployment, the machine may operate in the capacity of either a serveror a client machine in server-client network environments, or it may actas a peer machine in peer-to-peer (or distributed) network environments.The machine may be an onboard vehicle system, wearable device, personalcomputer (PC), a tablet PC, a hybrid tablet, a personal digitalassistant (PDA), a mobile telephone, or any machine capable of executinginstructions (sequential or otherwise) that specify actions to be takenby that machine. Further, while only a single machine is illustrated,the term “machine” shall also be taken to include any collection ofmachines that individually or jointly execute a set (or multiple sets)of instructions to perform any one or more of the methodologiesdiscussed herein. Similarly, the term “processor-based system” shall betaken to include any set of one or more machines that are controlled byor operated by a processor (e.g., a computer) to individually or jointlyexecute instructions to perform any one or more of the methodologiesdiscussed herein.

Example computer system 1200 includes at least one processor 1202 (e.g.,a central processing unit (CPU), a graphics processing unit (GPU) orboth, processor cores, compute nodes, etc.), a main memory 1204 and astatic memory 1206, which communicate with each other via a link 1208(e.g., bus). The computer system 1200 may further include a videodisplay unit 1210, an alphanumeric input device 1212 (e.g., a keyboard),and a user interface (UI) navigation device 1214 (e.g., a mouse). In oneembodiment, the video display unit 1210, input device 1212 and UInavigation device 1214 are incorporated into a touch screen display. Thecomputer system 1200 may additionally include a storage device 1216(e.g., a drive unit), a signal generation device 1218 (e.g., a speaker),a network interface device 1220, and one or more sensors (not shown),such as a global positioning system (GPS) sensor, compass,accelerometer, or another sensor.

The storage device 1216 includes a machine-readable medium 1222 on whichis stored one or more sets of data structures and instructions 1224(e.g., software) embodying or utilized by any one or more of themethodologies or functions described herein. The instructions 1224 mayalso reside, completely or at least partially, within the main memory1204, static memory 1206, and/or within the processor 1202 duringexecution thereof by the computer system 1200, with the main memory1204, static memory 1206, and the processor 1202 also constitutingmachine-readable media.

While the machine-readable medium 1222 is illustrated in an exampleembodiment to be a single medium, the term “machine-readable medium” mayinclude a single medium or multiple media (e.g., a centralized ordistributed database, and/or associated caches and servers) that storethe one or more instructions 1224. The term “machine-readable medium”shall also be taken to include any tangible medium that is capable ofstoring, encoding or carrying instructions for execution by the machineand that cause the machine to perform any one or more of themethodologies of the present disclosure or that is capable of storing,encoding or carrying data structures utilized by or associated with suchinstructions. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, andoptical and magnetic media. Specific examples of machine-readable mediainclude non-volatile memory, including but not limited to, by way ofexample, semiconductor memory devices (e.g., electrically programmableread-only memory (EPROM), electrically erasable programmable read-onlymemory (EEPROM)) and flash memory devices; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD-ROM and DVD-ROM disks.

The instructions 1224 may further be transmitted or received over acommunications network 1226 using a transmission medium via the networkinterface device 1220 utilizing any one of a number of well-knowntransfer protocols (e.g., HTTP). Examples of communication networksinclude a local area network (LAN), a wide area network (WAN), theInternet, mobile telephone networks, plain old telephone (POTS)networks, and wireless data networks (e.g., Wi-Fi, 3, and 4G LTE/LTE-Aor WiMAX networks). The term “transmission medium” shall be taken toinclude any intangible medium that is capable of storing, encoding, orcarrying instructions for execution by the machine, and includes digitalor analog communications signals or other intangible medium tofacilitate communication of such software.

The above detailed description includes references to the accompanyingdrawings, which form a part of the detailed description. The drawingsshow, by way of illustration, specific embodiments that may bepracticed. These embodiments are also referred to herein as “examples.”Such examples may include elements in addition to those shown ordescribed. However, also contemplated are examples that include theelements shown or described. Moreover, also contemplate are examplesusing any combination or permutation of those elements shown ordescribed (or one or more aspects thereof), either with respect to aparticular example (or one or more aspects thereof), or with respect toother examples (or one or more aspects thereof) shown or describedherein.

What is claimed is:
 1. A method comprising: accessing a reportdefinition template, the report definition template identifying a set ofdata requirements for a report; mapping the set of data requirements forthe report to a corresponding semantic object in a semantic ontology;parsing a semantic map to determine a database table storing data fromthe corresponding semantic object; retrieving the data for thecorresponding semantic object from the database table; and generating areport data file that adheres to the semantic ontology based in part onthe retrieved data.
 2. The method of claim 1, further comprisingtransmitting a logical location of the report data file, a logicallocation of the semantic map, and a logical location of the semanticontology to a blockchain node for adding to a report block in theblockchain node.
 3. The method of claim 1, wherein the requirementscorrespond to one of a format type, required data, or a time period. 4.The method of claim 1, wherein the semantic ontology defines how tocalculate the data for the report.
 5. The method of claim 4, the furthercomprising using logic annotations with the semantic ontology tocalculate the data for the report.
 6. The method of claim 5, the methodfurther comprising storing the logic annotations in an XML format thatadheres to the semantic ontology.
 7. The method of claim 1, wherein thesemantic map is parsed to determine what features in the database tablemaps to a classification.
 8. A non-transitory computer readable mediumcomprising instructions, which when executed by at least one processor,configure the processor to perform operations comprising: accessing areport definition template, the report definition template identifying aset of data requirements for a report; mapping the set of datarequirements for the report to a corresponding semantic object in asemantic ontology; parsing a semantic map to determine a database tablestoring data from the corresponding semantic object; retrieving the datafor the corresponding semantic object from the database table; andgenerating a report data file that adheres to the semantic ontologybased in part on the retrieved data.
 9. The non-transitory computerreadable medium of claim 8, the operations further comprisingtransmitting a logical location of the report data file, a logicallocation of the semantic map, and a logical location of the semanticontology to a blockchain node for adding to a report block in theblockchain node.
 10. The non-transitory computer readable medium ofclaim 8, wherein the requirements correspond to one of a format type,required data, or a time period.
 11. The non-transitory computerreadable medium of claim 8, wherein the semantic ontology defines how tocalculate the data for the report.
 12. The non-transitory computerreadable medium of claim 11, the operations further comprising usinglogic annotations with the semantic ontology to calculate the data forthe report.
 13. The non-transitory computer readable medium of claim 12,the operations further comprising storing the logic annotations in anXML format that adheres to the semantic ontology.
 14. The non-transitorycomputer readable medium of claim 8, wherein the semantic map is parsedto determine what features in the database table maps to aclassification.
 15. A system comprising: at least one processor; astorage device comprising instructions, which when executed by the atleast one processor, configure the processor to perform operationscomprising: accessing a report definition template, the reportdefinition template identifying a set of data requirements for a report;mapping the set of data requirements for the report to a correspondingsemantic object in a semantic ontology; parsing a semantic map todetermine a database table storing data from the corresponding semanticobject; retrieving the data for the corresponding semantic object fromthe database table; and generating a report data file that adheres tothe semantic ontology based in part on the retrieved data.
 16. Thesystem of claim 15, the operations further comprising transmitting alogical location of the report data file, a logical location of thesemantic map, and a logical location of the semantic ontology to ablockchain node for adding to a report block in the blockchain node. 17.The system of claim 15, wherein the requirements correspond to one of aformat type, required data, or a time period.
 18. The system of claim15, wherein the semantic ontology defines how to calculate the data forthe report.
 19. The system of claim 18, the operations furthercomprising; using logic annotations with the semantic ontology tocalculate the data for the report; and storing the logic annotations inan XML format that adheres to the semantic ontology.
 20. The system ofclaim 15, wherein the semantic map is parsed to determine what featuresin the database table maps to a classification.